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Background 

This invention relates generally to processor-based 
systems including personal computers, telephones, set -top 
boxes, and personal digital assistants, to mention a few 
examples . 

Commonly a set of networked processor-based systems 
may be served by a server that provides information to and 
receives information from a plurality of clients in the 
network. A server may need to determine the current 
characteristics of a client in the network. This may be 
important to determining what software can be downloaded 
from the server to the client or to determine what tasks 
the client may be called upon to perform. For example, the 
server may wish to know the client's processor speed, 
memory size, screen size, input protocols to mention a few 
examples . 

Conventionally, the assessment of client capabilities 
may be based on what is known as a classmark. Classmarks 
are hard-coded values that provide information about the 
capabilities of the client. The format, content and 
information conveyed by classmarks must be determined prior 
to deployment of the client itself. 



As a result, classmarks are not amenable to changing 
circumstances, conditions and hardware and software 
environments. The types of services being deployed by a 
network may evolve relatively rapidly. However, the 
classmark scheme relies on the assumption that all relevant 
capabilities may be incorporated prior to the first client 
shipment. As a result, the classmark scheme is relatively 
inflexible . 

Thus, there is a need for better ways to determine 
client capabilities in networks. 

Brief Description of the Drawings 
Figure 1 is a schematic depiction of one embodiment of 

the present invention; 

Figure 2 is a flow chart for software on a server in 

accordance with one embodiment of the present invention; 

and 

Figure 3 is a flow chart for software on a client in 
accordance with one embodiment of the present invention. 

Detailed Description 
Referring to Figure 1, a network 10 may include a 
server 12 coupled to a client 24 by a link 20. The link 20 
may be a wired or wireless link. Suitable wired links 20 
include telephone lines, optical lines, and conventional 
cables. Suitable wireless links 20 include radio frequency 
and infrared links. 



While only one client 24 is illustrated, commonly a 
plurality of clients 24 may be coupled by one or more links 
20 to the server 12. Thus, a conventional client server 
relationship may be established. The client server 
relationship may be as a conventional local area network 
(LAN) in one embodiment. As another embodiment, the 
network may be part of a telephone network. The telephone 
network may be circuit -based or packet -based. 

Thus, in one example, the client 24 may be a 
particular telephone and the server 12 may be a base 
station. In such case, the link 20 may be a wired or 
wireless link depending on the type of telephone network. 

The server 12 may include an interface 18 that is 
coupled to the link 20 as well as a storage 14 that stores 
software 16 and 28. Conventionally, the server 12 is 
processor-based, meaning that it includes at least one or 
more processors to implement various functions. 

Similarly, the client 24 is also processor-based. The 
client 24 may include an interface 22 to a link 20. 

When the server 12 needs to determine the capabilities 
of the client 24, it may run the software 16 shown in 
Figure 2 in accordance with one embodiment of the present 
invention. Initially, the server 12 selects an appropriate 
client probe routine from a probe routine library as 
indicated in block 30. The probe routine library may be a 
plurality of probe routines that may be utilized depending 



on the characteristics of the client 24. Thus, the server 
12 applies the information it has about the client 24 in 
order to assess and determine the appropriate probe 
routine . 

In one embodiment of the present invention, the 
classmark information may be utilized to select the 
appropriate probe routine. In such case, rather than using 
the classmark as the sole client information, the classmark 
is merely utilized to determine which probe routine to send 
to a particular client 24 as indicated in block 30. 

Next, the probe routine is transferred to the client 
24 over the link 2 0 as indicated in block 32. The server 
12 then awaits a response from the probe routine at the 
client 24 as indicated in block 34. The probe routine 
response may then be used in one embodiment to configure 
the content or application to be downloaded to the client 
22 as indicated in block 36. Thus, the probe routine may 
be utilized to provide services that are specifically 
tailored to the characteristics or capabilities of a 
particular client 24. 

Because the probe routines are stored in the storage 
14 on the server 12 in accordance with one embodiment, they 
can be essentially continuously updated. Thus, the probe 
routines may be refined to better query the client 24 given 
the current operating circumstances, conditions, and 
updates to mention a few examples. As a result, the use of 



the probe routine may be more flexible than the classmark 
scheme in some situations. 

Turning next to Figure 3, the probe routine software 
28 running on the client 24 is initialized as indicated in 
block 4 0 in accordance with one embodiment of the present 
invention. Once the client software 28 is provided by the 
server 12 to the client 24, it initializes on the client 24 
as indicated in block 40. The software 28 then executes on 
the client 24, scanning the operating environment of the 
client 24 for details about device capabilities as 
indicated in block 42. For example, the software 2 8 may 
examine various files including Registries on the client 
24 . 

The software 28 then develops a capability description 
based on the information gleaned from the client 24 as 
indicated in block 44. That information is transformed 
into an appropriate message to be sent from the client 24 
to the server 12. Finally, the capability message is sent 
by the client 24 back to the server 12 as indicated in 
block 46. 

In one embodiment of the present invention, the 
software 28 may then remain resident on the client 24. 
Subsequently, that same software 28 may be reactivated or, 
if necessary, new software or updated software may be sent 
from the server 12 to the client 24. 



While the present invention has been described with 
respect to a limited number of embodiments, those skilled 
in the art will appreciate numerous modifications and 
variations therefrom. It is intended that the appended 
claims cover all such modifications and variations as fall 
within the true spirit and scope of this present invention. 

What is claimed is: 
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